iT邦幫忙

第 12 屆 iThome 鐵人賽

DAY 4
1

筆者不只是SCYLLA小白,其實也算是半個分散式系統的小白。

想到當初原來是太欠缺分散式系統的基本概念,接觸mongoDB時磕磕碰碰地一路辛苦,所以文章裡面多少也簡介一些分散式系統的概念。

並不是SCYLLA的學習門檻太高,是如果以前都沒碰過分散式結構的前提,會變成一次要學兩種東西,分散式系統+分散式的NoSQL DB。

回歸正題,別於關聯式DB在機器上的系統結構(單台/主從),CASSANDRA/SCYLLA就是一種多台的分散式的架構,分散式的DB。

關聯式DB一定有個主(master)節點,分散式的架構去中心化,並沒有master-slave的概念。

關聯式DB的master節點,往往也是效能瓶頸的所在,因為slave可以多台,關鍵的master只能有一台,寫入的操作都是往master擠。

雖然說這可能是關聯式DB的瓶頸,相對的,這也是關聯式DB巨大的優勢,它保證了資料的一致性,基本上有寫到master的資料,不用擔心slave拿到的資料會不一樣,當然同步落後問題,不在此列。

分散式DB就沒有辦法很輕鬆的達到資料寫入可靠性保證,因為架構的關係,在短暫的同一個時間點,有可能在不同節點上的資料會有所出入,尤其每次寫到的機器,不一定是在同一台,這就牽扯資料一致性的問題。

一致性嚴格來說又可以分成幾種,順序(強)一致性,因果一致性,對於CASSANDRA/SCYLLA,策略上是追求資料最終(弱)一致性,

說到這裡,對於分散式系統概念,我們要提一下CAP定理

CAP

以下引用wiki上的解釋,以及筆者找到一些更直白的敘述,希望幫助大家更明白這3個原則在講什麼:

在理論計算機科學中,CAP定理(CAP theorem),又被稱作布魯爾定理(Brewer's theorem),它指出對於一個分布式計算系統來說,不可能同時滿足以下三點:

  • 一致性(Consistency) (等同於所有節點訪問同一份最新的數據副本)

所有資料庫客戶端同時更新,用同樣的查詢,一定取得相同的值。

  • 可用性(Availability)(每次請求都能獲取到非錯的響應——但是不保證獲取的數據為最新數據)

總是可以讀寫,不會因為資料失效,而遇到無法讀取之類的狀況。

  • 分區容錯性(Partition tolerance)(以實際效果而言,分區相當於對通信的時限要求。系統如果不能在時限內達成數據一致性,就意味著發生了分區的情況,必須就當前操作在C和A之間做出選擇。)

數個節點之間的網路或溝通出現問題,還是可以對外提供服務。

根據定理,分布式系統只能滿足三項中的兩項而不可能滿足全部三項。理解CAP理論的最簡單方式是想像兩個節點分處分區兩側。允許至少一個節點更新狀態會導致數據不一致,即喪失了C性質。如果為了保證數據一致性,將分區一側的節點設置為不可用,那麼又喪失了A性質。除非兩個節點可以互相通信,才能既保證C又保證A,這又會導致喪失P性質。

CAP 指的是分散式系統就會有這樣的特性,並非特定發生在NoSQL的分散式DB身上。

由上面定理可知,CASSANDRA/SCYLLA這種分散式的DB,一定要在3原則當中,選擇犧牲某些東西,於是定位在追求最終一致性,而換取其他方面的優秀表現。

與之相比,關聯式DB,大家會容易討論到的就是ACID特性,關聯式DB架構設計的關係,可以很好地達成ACID。

要注意一點,並不是指CAP和ACID是相同層次的討論議題。

關聯式DB跟CAP絕對無關,因為這是分散式架構的議題,關聯式DB也做不到分散式架構。

分散式架構,卻可以追求ACID,但是稍微了解分散式架構的概念,要做ACID(簡單來說,可以理解為想做交易機制),就大概可以想像有多麽困難,光是節點與節點的溝通上面就會讓你頭痛萬分。

常見的解法或策略,可能聽說過2PC的做法,或者補償機制之類的,但是成本額貴且很有局限性,以及要額外考量的衍生問題也會很多。

說明這麼多理論的層面的東西,是由衷希望能夠幫助大家,在挑選什麼樣的DB作為最佳的應用場景,適用性最好,有個決策的依據與判斷。

工具用得不對,不能怪工具爛嘛。

高可擴充性的分散式系統

服務設備的擴充,簡單分兩種方式,垂直擴充和水平擴充。

垂直擴充指的是單點機器設備的性能提升,今天機器不夠力,換一台更好更貴的機器上去,那麼服務的量能就明顯提升上去了,但是短時間內,或者遇到緊急狀況時,這樣的做法,絕對不是那麼容易。

水平擴充,指的是增加服務機器的數量,在現代虛擬化、容器化、上雲端盛行的時代,這樣的擴充是分秒就能完成的事情,而且可以作到自動化,達到服務不中斷的優勢。

光是水平擴充容易這項優點,就值得思慮應用的場景了,無關今天用的DB是SCYLLA還是CASSANDRA,甚至用Mongo DB,都是一樣的,因為這是分散式的架構。

在此我們就可以知道,如果你的服務量級一直在擴張,對於擔心DB容量不夠,速度隨著時間漸漸變慢,或者本身服務的處理資料量就非常巨大,寫入的需求壓不下來,系統的瓶頸卡在DB的處理上,那麼也許就這點來說,就可以考慮用NoSQL來實作。

重要資料的處理

有些關鍵的資料,除了萬分要求可靠的一致性以外,處理速度上也有所要求。

如金錢、庫存、成立訂單部分,遇到這類需要做交易機制的處理,在分散式系統硬要做,又要做得好,除了成本代價高,也很容易衍生問題。

雖然分散式系統好擴充,但要做交易機制處理的部分,暴露的風險非常嚴重,這些部分的處置,基本上一點都不能錯,試想比方說,銀行系統若不小心把你的錢弄丟了,你會做何感想?

於是重要的資料,仍然建議使用關聯式DB,寧願系統慢,也不要有出差錯的可能。

所以筆者的工作環境,關聯式DB和SCYLLA是併行使用著,就是這麼簡單的道理。


上一篇
Day3. 安裝
下一篇
Day5 . 資料與架構層次
系列文
scylla 從零開始攻略30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言